!S = f= IN THE UNITED STATES PATENT AND TRADEMARK OFFTCF 

CERTIFICATE OF EXPRESS MAILING 
I het ^^ rWy that this paper and the documents and/or fees referred to as 

attac^^egin are being deposited with the United States Postal Service -r.-<.xT jt . -r-.T,-^^T-r ^^"^ 

on JuTTT^ 1999 in an envelope as "Express Mail Post Office to FltSt Named Inventor: BLOCK 

Addressee" service under 37 CFR § 1 /Q, Mailing Label Number 3^ 
EL100015935US, addressed to thg^ssistatK Commissioner for Patents, 
jIdC 20231. 



Ja^^irr 



UTILITY PATENT APPLICATION TRANSMITTAL (37 CFR. § 1.53(b)) 



Assistant Commissioner for Patents 
Box Patent Application 
|\[ashington, DC 20231 

giir: This is a request for filing a patent application under 37 CFR. § 1 .53(b) in the name of inventors: 
\ 1 Joshua J. Bloch 

fi>r: INHERITABLE THREAD-LOCAL STORAGE 

Application Elements: 

= J 1^ 20 Pages of Specification, Claims and Abstract 
I/KI 07 Sheets of Informal Drawings 
I 02 Pages Combined Declaration and Power of Attorney 

Accompan ying Application Parts : 

Assignment and Assignment Recordation Cover Sheet (recording fee of $40.00 enclosed) 
37 CFR 3.73(b) Statement by Assignee 
Information Disclosure Statement with Form PTO-1449 

1^ Copies of IDS Citations 
Preliminary Amendment 
Return Receipt Postcard 
Small Entity Statement(s) 
Other: 



I I Duplicate for 
fee processing 



□ 



□ 
□ 



(Revised 12/97, Pat App Trans 53(b) Reg 



Page 1 of 2 



Fee Calculation (37 CFR § 1.16^ 





(Col. 1) (Col. 2) 


SMALL ENTITY 


OR 


LARGE ENTITY 




NO. FILED NO. EXTRA 


RATE FEE 




RATE FEE 


BASIC FEE 




$380 $ 


OR 


$760 $ 760.00 


TOTAL CLAIMS 


33 -20= 13 


X 9 = $ 


OR 


X 18=$ 234.00 


INDEP CLAIMS 


07 -03 = 04 


X 39 = $ 


OR 


X 78 =$ 312.00 


[ ] Multiple Dependent Claim Presented 


$130 = $ 


OR 


$260 =$ 


* If the difference in Col. 1 is less 


Total $ 


OR 


Total $ 1,306.00 



than zero, enter "0" in Col. 2. 



IXI Check No. 5191 in the amount of $1,346.00 is enclosed. 

^] The Commissioner is authorized to charge any fees beyond the amount enclosed which may be 
required, or to credit any overpayment, to Deposit Account No. 50-0388 (Order No. SUN1P247 ). 

g General Authorization for Petition for Extension of Time (37 CFR §1 .1 361 

7 1^ Applicants hereby make and generally authorize any Petitions for Extensions of Time as may be 
^ needed for any subsequent filings. The Commissioner is also authorized to charge any extension fees under 
,^ 37 CFR §1 .17 as may be needed to Deposit Account No. 50-0388 (Order No. SUN1P247 V 



Please send correspondence to the following address: 



Customer Number 022434 

BEYER & WEAVER, LLP 
P.O. Box 61059 
Palo Alto, CA 94306 
Telephone (650) 493-2100 
Fax (6S0) 493-2102 

Date: "7~ H 

DoyfelB«^^ohnson 
Registration No. 39,240 



illlHIl 

022434 




^Revised 1 2/97 Pat Ann Trans Rpp 



Paee 2 of 2 



Attorney Docket No. SUN1P247/P4133 



Application FOR U.S. Patent 

Inheritable thread-local storage 



Inventors: Joshua J. Bloch 

1 199 Cordelia Avenue 
San Jose, CA 95129 



A Citizen of the United States of America 



Assignee: Sun Microsystems, Inc. 

901 San Antonio Road 
Palo Alto, CA 94303 

A Delaware Corporation 



Entity: Large 



Beyer & Weaver, LLP 
P.O. Box 61059 
Palo Alto, CA 94306 
Telephone (650) 493-2100 



SDB/DBJ 



INHERITABLE THREAD-LOCAL STORAGE 

BACKGROUND OF THE TNVENTTON 

1. Field of the Invention 

The present invention relates generally to the field of computer software, and more 
particularly to inheritable thread-local storage. 

2. Description of the Related Art 

Modem multitasking operating systems support multiple threads, which allow many 
activities to execute simultaneously. For example, searches on multiple remote databases 
may all be laimched by one task, each search corresponding to a unique thread, and executed 
simultaneously. Oftentimes, it is convenient to have storage that is unique to each thread. 
Unfortunately, most programming languages do not support such storage. However, there is 
a standard software mechanism for threads to associate implicit scope information with 
themselves, known variously as "thread-local data" or "thread-specific data." This facihty 
exists in many threading facilities, including POSIX Threads ("Pthreads") and Win32 
Threads. 

Under POSIX, thread-specific data allows each thread to have a separate copy of a 
variable, which is indexed by a common "key" value. A key is created and each thread 
independently sets or gets its own unique value for that key. The key is the same for all the 
threads, but each thread can associate its own unique value with the shared key. Each thread 
can change its private value for a key without affecting the key or any other thread's value for 
the key. When the threading system is asked for a new key, a new variable is created. This type 
of "key" system is not secure, however, since the keys can be forged and data, accessed without 
permission. The POSIX thread-specific data mechanism is explained in fiirther detail in 
Programming in POSIX Threads, David R. Butenhof, Addison-Wesley, 1997, herein 



incorporated by reference. A similar mechanism is available in the Windows 95 operating 
system, and is discussed in Programming Windows 95, Charles Petzold, Microsoft Press, 1996, 
herein incorporated by reference. 

The Java ™ programming language, created by Sun Microsystems, is somewhat unique 
among programming languages in that it has built-in thread-local storage support. Specifically, 
there is a pubhc class "ThreadLocal" that provides thread-local variables. The thread-local 
variables differ from the other "normal" Java variables in that each thread that accesses a thread- 
local variable (via a get or set method) has its own, independently initiahzed copy of the 
variable. ThreadLocal objects are typically private static variables in classes that want to 
associate a state with a thread, such as a user ID or a transaction ID. Each thread holds an 
imphcit reference to its copy of a ThreadLocal as long as the thread is in existence and is 
accessible. After a thread termmates, all of its copies of ThreadLocal variables are subject to 
garbage collection, unless other references to these copies exist. Figure 3 is a table illustrating 
the API specification for the class ThreadLocal. 

For many programming apphcations, is often desirable for threads to carry with them 
some implicit "scope" information, such as the principal or transaction on whose behalf the 
thread is executing. When a thread ("the parenf ) creates another thread ("the child"), it is often 
desirable that this scope information be automatically transmitted from parent to child, in a 
manner that may depend on the details of the scope information in question. The thread- 
specific data (hereinafter "thread-local data" or "thread-local storage") mechanisms described 
above do not solve this problem, however, since values are not passed from parent threads to 
child threads. 



In view of the foregoing, it would be desirable to have a thread-local storage mechanism 
in which a child thread can inherit its parent's values directly, or in which a child thread could 
inherit values which are some functions of the parent's values. 

SUMMARY OF THE INVENTTON 

In a threading mechanism, the present invention is a system and method for providing 
automatic value inheritance when a parent thread creates a child thread. Upon the creation of a 
child thread, the system iterates over all of the inheritable thread-local values associated with the 
parent thread and initializes the child's values of these inheritable thread-local values, based on 
an appropriate childValue method. 

In a fnst embodiment, for each thread, a hash table maps each thread local object to a 
value. In a preferred implementation, the hash table is two separate logical maps - one for 
inheritable values and one for non-inheritable values. When a thread creates a child, the system 
iterates over the inheritable value map to create the child's values. An inheritance protocol (i.e. 
the "childValue" method) may be performed on the values in order to calculate the child's value 
as a ftmction of the parent's value, if desired. 

In an alternative embodiment, the two hash tables in the first embodiment can be 
combined into one table, with each entry having a flag to identify the inheritable values. 

In a second embodiment of the present invention, for each thread-local variable, a hash 
table maps each thread to a value. An object reference to a current thread is used as a look-up 
key in the hash table to find the value associated with this thread. For each thread, a linked Ust 
called "values" links all the inheritable thread-local values associated with the thread. The head 
pointer to the linked Ust of inheritable values is stored in the thread object. When a parent 
thread creates a child thread, the system iterates over the linked hst of thread-local values 



pertaining to the parent thread. For each parent value, a "childValue" method is invoked to 
initiaUze the associated child's value. 

In a preferred embodiment, the present invention is implemented in the Java ™ 
programming language. The hiheritableThreadLocal class of the present invention extends the 
ThreadLocal class to provide inheritance of values from a parent thread to a child thread. When 
a child thread is created, the child receives initial values for all MieritableThreadLocals for 
which the parent has values. Normally, the child's values will be identical to the parent's 
values. However, the child's value can be made to be an arbitrary function of the parent's value 
by overriding the "childValue" method in the InheritableThreadLocal class. 

BRIEF DESCRTPTTON OF THE DRAWTNOS 

The present invention will be readily understood by the following detailed description 
in conjunction with the accompanying drawings, wherein like reference niunerals designate 
like structural elements, and in which: 

Figure 1 is a block diagram of a computer system suitable for implementing the 
present invention; 

Figure 2 is a block diagram illustrating value inheritance for a child thread; 
Figure 3 is table of a prior art ThreadLocal API specification; 
Figure 4 is a table of the InheritableThreadLocal API specification of the present 
invention; 

Figure 5 is a diagram illustrating a first embodiment of the present invention; 
Figure 6 is a diagram of an alternative implementation of the first embodiment of the 
present invention; and 

Figure 7 is a diagram illustrating a second embodiment of the present invention. 



DETAILED DESCRIPTION OF THE TNVENTTON 

The following description is provided to enable any person skilled in the art to make 
and use the invention and sets forth the best modes contemplated by the inventor for carrying 
out the invention. Various modifications, however, will remain readily apparent to those 
skilled in the art, since the basic principles of the present invention have been defined herein 
specifically to provide an inheritable thread-local storage mechanism. 

The present invention employs various computer-implemented operations involving 
data stored in computer systems. These operations include, but are not hmited to, those 
requiring physical manipulation of physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals capable of being stored, transferred, 
combined, compared, and otherwise manipulated. The operations described herein that form 
part of the invention are useful machine operations. The manipulations performed are often 
referred to in terms, such as, producing, identifying, running, determining, comparing, 
executing, downloading, or detecting. It is sometimes convenient, principally for reasons of 
common usage, to refer to these electrical or magnetic signals as bits, values, elements, 
variables, characters, data, or the like. It should remembered, however, that all of these and 
similar terms are to be associated with the appropriate physical quantities and are merely 
convenient labels apphed to these quantities. 

The present invention also relates to a device, system or apparatus for performing the 
aforementioned operations. The system may be specially constructed for the required 
purposes, or it may be a general purpose computer selectively activated or configured by a 
computer program stored in tiie computer. The processes presented above are not inherentiy 
related to any particular computer or otiier computing apparatus. In particular, various 



general-purpose computers may be used with programs written in accordance with the 
teachings herein, or, alternatively, it may be more convenient to construct a more specialized 
computer system to perform the required operations. 

FIG. 1 is a block diagram of a general purpose computer system 100 suitable for 
carrying out the processing in accordance with one embodiment of the present invention. 
Figure 1 illustrates one embodiment of a general purpose computer system. Other computer 
system architectures and configurations can be used for carrying out the processing of the 
present invention. Computer system 100, made up of various subsystems described below, 
includes at least one microprocessor subsystem (also referred to as a central processing unit, 
or CPU) 102. That is, CPU 102 can be implemented by a single-chip processor or by 
multiple processors. It should be noted that in re-configurable computing systems, CPU 102 
can be distributed amongst a group of programmable logic devices. In such a system, the 
programmable logic devices can be reconfigured as needed to control the operation of 
computer system 100. In this way, the manipulation of input data is distributed amongst the 
group of programmable logic devices. CPU 102 is a general purpose digital processor which 
controls the operation of the computer system 100. Using instructions retrieved fi-om 
memory, the CPU 102 controls the reception and manipulation of input data, and the output 
and display of data on output devices. 

CPU 102 is coupled bi-directionally with a first primary storage 104, typically a 
random access memory (RAM), and vini-directionally with a second primary storage area 
106, typically a read-only memory (ROM), via a memory bus 108. As is well known in the 
art, primary storage 104 can be used as a general storage area and as scratch-pad memory, and 
can also be used to store input data and processed data. It can also store programming 
instinctions and data, in the form of data objects, in addition to other data and instructions for 



processes operating on CPU 102, and is used typically used for fast transfer of data and 
instructions in a bi-directional manner over the memory bus 108. Also as well known in the 
art, primary storage 106 typically includes basic operating instructions, program code, data 
and objects used by the CPU 102 to perfomi its functions. Primary storage devices 104 and 
1 06 may include any suitable computer-readable storage media, described below, depending 
on whether, for example, data access needs to be bi-directional or uni-directional. CPU 102 
can also directly and very rapidly retrieve and store frequently needed data in a cache 
memory 110. 

A removable mass storage device 1 12 provides additional data storage capacity for the 
computer system 100, and is coupled either bi-directionally or uni-directionally to CPU 102 
via a peripheral bus 1 14. For example, a specific removable mass storage device commonly 
known as a CD-ROM typically passes data uni-directionally to the CPU 102, whereas a 
floppy disk can pass data bi-directionally to the CPU 102. Storage 112 may also include 
computer-readable media such as magnetic tape, flash memory, signals embodied on a carrier 
wave, PC-CARDS, portable mass storage devices, holographic storage devices, and other 
storage devices. A fixed mass storage 116 also provides additional data storage capacity and 
is coupled bi-directionally to CPU 102 via peripheral bus 1 14. The most common example of 
mass storage 1 16 is a hard disk drive. Generally, access to these media is slower than access 
to primary storages 104 and 106. 

Mass storage 1 12 and 1 16 generally store additional programming instructions, data, 
and the like that typically are not in active use by the CPU 102. It will be appreciated that the 
information retained within mass storage 1 12 and 1 16 may be incorporated, if needed, in 
standard fashion as part of primary storage 104 (e.g. RAM) as virtual memory. 



In addition to providing CPU 102 access to storage subsystems, the peripheral bus 
1 14 is used to provide access other subsystems and devices as well. In the described 
embodiment, these include a display monitor 118 and adapter 120, a printer device 122, a 
network interface 124, an auxihary input/output device interface 126, a sound card 128 and 
speakers 130, and other subsystems as needed. 

The network interface 124 allows CPU 102 to be coupled to another computer, 
computer network, or telecommunications network using a network connection as shown. 
Through the network interface 124, it is contemplated that the CPU 102 might receive 
information, e.g., data objects or program instructions, from another network, or might output 
information to another network in the course of performing the above-described method 
steps. Information, often represented as a sequence of instructions to be executed on a CPU, 
may be received from and outputted to another network, for example, in the form of a 
computer data signal embodied in a carrier wave. An interface card or similar device and 
appropriate software implemented by CPU 102 can be used to connect the computer system 
100 to an external network and fransfer data according to standard protocols. That is, method 
embodiments of the present invention may execute solely upon CPU 102, or may be 
performed across a network such as the Internet, intranet networks, or local area networks, in 
conjunction with a remote CPU that shares a portion of the processing. Additional mass 
storage devices (not shown) may also be connected to CPU 102 through network interface 
124. 

Auxiliary I/O device interface 126 represents general and customized interfaces that 
allow the CPU 102 to send and, more typically, receive data from other devices such as 
microphones, touch-sensitive displays, fransducer card readers, tape readers, voice or 



handwriting recognizers, biometrics readers, cameras, portable mass storage devices, and 
other computers. 

Also coupled to the CPU 102 is a keyboard controller 132 via a local bus 134 for 
receiving input from a keyboard 136 or a pointer device 138, and sending decoded symbols 
from the keyboard 136 or pointer device 138 to the CPU 102. The pointer device may be a 
mouse, stylus, track ball, or tablet, and is useftil for interacting with a graphical user interface. 

In addition, embodiments of the present invention fixrther relate to computer storage 
products with a computer readable medium that contain program code for performing various 
computer-implemented operations. The computer-readable medium is any data storage 
device that can store data which can thereafter be read by a computer system. The media and 
program code may be those specially designed and constructed for the purposes of the present 
invention, or they may be of the kind well known to those of ordinary skill in the computer 
software arts. Examples of computer-readable media include, but are not lunited to, all the 
media mentioned above: magnetic media such as hard disks, floppy disks, and magnetic tape; 
optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and 
specially configured hardware devices such as apphcation-specific integrated circuits 
(ASICs), programmable logic devices (PLDs), and ROM and RAM devices. The computer- 
readable medium can also be distributed as a data signal embodied in a carrier wave over a 
network of coupled computer systems so that the computer-readable code is stored and 
executed in a distributed fashion. Examples of program code include both machine code, as 
produced, for example, by a compiler, or files containing higher level code that may be 
executed using an interpreter. 

It will be appreciated by those skilled in the art that the above described hardware and 
software elements are of standard design and construction. Other computer systems suitable 



for use with the invention may include additional or fewer subsystems. In addition, memory 
bus 108, peripheral bus 1 14, and local bus 134 are illustrative of any interconnection scheme 
serving to Hnk the subsystems. For example, a local bus could be used to connect the CPU to 
fixed mass storage 116 and display adapter 120. The computer system shown in FIG. 1 is but 
an example of a computer system suitable for use with the invention. Other computer 
architectures having different configurations of subsystems may also be utihzed. 

In general, the inheritable thread-local storage of the present invention is similar to 
ordinary thread-local storage, available in most modem threading facilities (such as POSIX 
Threads or Win32 Threads). However, the inheritable thread-local storage values of the present 
invention are automatically passed from a parent thread to a child thread ("inherited") when a 
child thread is created, as shown in Figure 2. In Figure 2, Thread 1 creates a new child, Thread 
1.1. Thread I's value lA is passed via the childValue method to the child Thread 1.1 as value 
1.1 A. Similarly, all other inheritable values associated with Thread 1 are transferred to Thread 
1.1. Thus, the child Thread 1 . 1 receives initial values for all inheritable thread-local variables 
for which the parent Thread 1 has values. Similarly, Thread 2 creates a new child. Thread 2.2, 
having an inherited value 2.1 A. 

The present invention is a general-purpose facility that overcomes the inheritance 
limitations of the prior art systems. Although the present invention is described with reference 
to a preferred embodiment in the Java programming language, the teachmgs of the present 
invention are applicable to any implementation supporting thread-local storage. The teachings 
or the present invention are particularly applicable to other programming languages that support 
threads. 

hi the presently preferred embodiment, the present invention is implemented in the Java 
programming language. By using Java, the present invention is able to take advantage of the 

-10- 



data security inherent in the language. The present implementation does not use "keys " but 
instead uses actual Java object references. An hiheritableThreadLocal class API specification of 
the present invention is illustrated in the table of Figure 4. When an object of type ThreadLocal 
or hiheritableThreadLocal is created, only someone with access to the object is allowed to read 
the variables, thus providmg improved data security, as compared to the "key" based systems. 

The hiheritableThreadLocal class of the present invention extends ThreadLocal to 
provide inheritance of values from a parent thread to a child thread. When a child thread is 
created, the child receives initial values for all InheritableThreadLocals for which the parent has 
values. Normally, the child's values will be identical to the parent's values. However, the 
child's value can be made to be an arbitrary function of the parent's value by overriding the 
"childValue" method in the hiheritableThreadLocal class. 

hi general, the present invention may be implemented by either mapping, for each 
thread-local variable, each thread to a value, or for each thread, mapping each thread-local 
variable to a value. Both embodiments are discussed in detail below. 

hi a first embodiment, for each thread, a hash table maps each thread-local variable to a 
value, as shown in Figure 5. More particularly, under Java, each thread-local variable is 
represented by a thread-local reference in the hash table and the thread-local reference is 
mapped to a particular value. In a preferred implementation, separate hash tables are 
maintained for each logical map - one for inheritable values and one for non-inheritable values. 
When a thread creates a child, the system iterates over the inheritable value map to create the 
child's values. An inheritance protocol can then be performed on the values in order to 
calculate the child's value as a fimction of the parent's value, if necessary. This implementation 
requires only one data structure, since no linked hst is necessary. Also, since the map is only 
accessed by the one thread associated with the values, no synchronization is required. In a 



second embodiment, described below, the maps are shared so a synchronization scheme must be 
implemented to ensure that the values are not inadvertently overwritten by another thread. 

In an alternative embodiment, the two hash tables in the first embodiment can be 
combined as shovm in Figure 6, with each entry having a logical flag to identify the mheritable 
values. As in the first embodiment, when a thread creates a child, the system iterates over the 
inheritable value to create the child's values. 

When a parent thread creates a child thread, the system iterates over the inheritable 
thread-local values pertaining to the parent thread. For each parent value, a "childValue" 
method is invoked to initialize the associated child's value. The default childValue method may 
be overridden to compute a desired value as a function of the parent value. If the childValue 
method has not been overridden, then by default, the value is just a copy of the parent's value. 
Thus, a child thread "inherits" the values (or some function of the values) of the parent thread. 

In a second embodiment of the present invention, for each thread-local variable, a hash 
table maps each thread to a value, as illustrated in Figure 7. An object reference to a current 
thread is used as a look-up key in the hash table to find the value associated with this thread. 
For each thread, a linked list called "values" links all the inheritable thread-local values 
associated with the thread. The head pointer to the linked hst of inheritable values is stored in 
the thread object. Note that for the non-inheritable values, a linked hst is not necessary since the 
child thread will not inherit these values. 

When a parent thread creates a child thread, the system iterates over the linked hst of 
thread-local values pertaining to the parent thread. For each parent value, a "childValue" 
method is invoked to initialize the associated child's value. The default childValue method may 
be overridden to compute a desired value as a fimction of the parent value. If the childValue 
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method has not been overridden, then by default, the value is just a copy of the parent's value. 
Thus, a child thread "inherits" the values (or some function of the values) of the parent thread. 

Further, in the second embodiment the hash table should contain only "weak references" 
to the threads, to allow the threads (and their thread-local values) to be garbage collected when 
they terminate, hi a preferred implementation, the hash tables are implemented as 
"WeakHashMap" objects in Java. 

hiheritable thread-local storage is used in preference to ordinary thread-local storage 
when the per-thread-attribute being maintained in the storage must be automatically h-ansmitted 
to any child threads that are created. Common uses include such attributes as the user ID or 
transaction ID on whose behalf a computation is taking place. Storing such an attribute in 
inheritable thread-local storage automatically turns child threads into "natural extensions" of 
their parent, operating on behalf of the same entity. 

The more general from of inheritable thread-local storage (where the child's initial value 
is an arbitrary function of the parent's) enables attributes where the child's initial value for the 
attribute is not identical to the parent's, but is derivable from it. For example, consider a 
dynamically scoped attribute, such as a transaction ID in a system that supports nested 
transactions. For such an attribute, each thread maintains in inheritable thread-local storage a 
"stack" of values representing the nested scopes currently in effect. The child's initial value for 
such a thread-local variable should be a stack with one element, that is, the top of the parent's 
stack. 

Thus, according to the present invention, upon thread creation, the system iterates over 
all of the inheritable thread-local values associated with a parent thread and mitializes the 
child's values of these inheritable thread-local values based on the appropriate child value 
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methods. The present invention is thereby able to provide automatic value inheritance upon 
child creation. 

Those skilled in the art will appreciate that various adaptations and modifications of the 
just-described preferred embodiments can be configured without departing from the scope and 
5 spirit of the invention. Therefore, it is to be understood that, within the scope of the appended 
claims, the invention may be practiced other than as specifically described herein. 
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CLAIMS 

What is c laimed is : 

1 . A method for providing inheritable thread-local storage from a parent thread to a 
child thread, the method comprising: 

for each thread-local variable, mapping each thread to a value; and 
when a parent thread creates a child thread, automatically iterating over the parent 
thread's values to create the child thread's initial values. 

2. The method of Claim 1, wherein the step of mapping comprises maintaining a 
map, associated with each thread object, that maps each thread-local variable to a value; and 
the step of iterating comprises iterating over the map. 

3. The method of Claim 1, wherein the step of mapping comprises maintaining a 
map, associated with each thread-local variable, that maps each thread to a value, and wherein 
for each thread a linked hst is maintained, the linked Ust linking inheritable thread-local 
values associated with the thread; and wherein the step of iterating comprises iterating over 
the linked list. 

4. The method of Claim 2, wherein the map comprises a hash table. 

5. The method of Claim 3, wherein the map comprises a hash table. 

6. The method of Claim 1, wherein a child thread's initial value is a copy of a 
corresponding parent thread's value. 

7. The method of Claim 1, wherein a child thread's value is a predetermined function 
of a corresponding parent thread's value. 

8. The method of Claim 4, wherein the step of mapping further comprises creating a 
separate hash table for inheritable values and a separate hash table for non-inheritable values. 



9. The method of Claim 5, wherein the step of mapping further comprises creating a 
hash table having both inheritable values and non-inheritable values, wherein each value has 
a flag to identify whether each value in the table is an inheritable or non-inheritable value. 

10. The method of Claim 2, wherein the method is implemented in a Java 
programming language as a class. 

1 1 . The method of Claim 3, wherein the method is implemented in a Java 
programming language as a class. 

12. A method for providing automatic value inheritance when a parent thread creates 
a child thread, the method comprising: 

associating, for each thread object, each thread-local variable with a value; and 
automatically iterating over the thread-local values to create a child value 
corresponding to each inheritable parent value, when a child is created. 

13. The method of Claim 12, wherein the child value is a copy of the corresponding 
parent value. 

14. The method of Claim 12, wherein the child value is a function of the 
corresponding parent value. 

15. The method of Claim 12, wherein the step of associating comprises creating a 
separate hash table for inheritable values and a separate hash table for non-inheritable values. 

16. The method of Claim 12, wherein the step of associating comprises creating a 
hash table having both inheritable values and non-inheritable values, wherein each value has 
a flag to identify whether each value in the table is an inheritable or non-inheritable value. 

17. The method of Claim 12, wherein the method is implemented in a Java 
programming language as a class. 
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18. A method for providing automatic value inheritance when a parent thread creates 
a child thread, the method comprising: 

associating, for each thread-local variable, each thread to a value, wherein for each 
thread a linked Ust is maintained, the linked hst linking inheritable thread-local values 
associated with the thread; and 

automatically iterating over the hnked list to create a child value corresponding to 
each inheritable parent value when a child is created. 

1 9. The method of Claim 1 8, wherein the child value is a copy of the corresponding 
parent value. 

20. The method of Claim 18, wherein the child value is a function of the 
corresponding parent value. 

2 1 . The method of Claim 1 8, wherein the method is implemented in a Java 
programming language as a class. 

22. A computer readable medium including computer program code for providing 
automatic value inheritance when a parent thread creates a child thread, the parent thread 
having at least one thread-local object value, the computer readable medium comprising: 

computer program code for associating, for each thread object, each thread-local 
variable with a value ; and 

computer program code for automatically iterating over the thread-local values to 
create a child value corresponding to each inheritable parent value, when a child is created. 

23. The medium of Claim 22, wherein the child value is a copy of the corresponding 
parent value. 

24. The medium of Claim 22, wherein the child value is a function of the 
corresponding parent value. 
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25. The medium of Claim 22, wherein the computer code for associating comprises 
code for creating a separate hash table for inheritable values and a separate hash table for non- 
inheritable values. 

26. The medium of Claim 22, wherein the computer code for associating comprises 
computer code for creating a hash table having both inheritable values and non-inheritable 
values, wherein each value has a flag to identify whether each value in the table is an 
inheritable or non-inheritable value. 

27. The medium of Claim 22, wherein the computer program code is implemented in 
a Java programming language as a class. 

28. A computer readable medium including computer program code for providing 
automatic value inheritance when a parent thread creates a child thread, the parent thread 
referencing at least one thread local variable, the computer readable medium comprising: 

computer program code for associating, for each thread-local variable, each thread to a 
value, wherein for each thread a linked list is maintained, the linked list linking inheritable 
thread local values associated with the thread; and 

computer program code for automatically iterating over the linked Hst to create a child 
value corresponding to each inheritable parent value, when a child is created. 

29. The medium of Claim 28, wherein the child value is a copy of the corresponding 
parent value. 

30. The medium of Claim 28, wherein the child value is a function of the 
corresponding parent value. 

3 1 . The medium of Claim 28, wherein the computer program code is implemented in 
a Java programming language as a class. 
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32. A computer system providing automatic inheritance of thread-local values of a 
parent thread to a child thread, the computer system comprising: 

a processor; and 

a computer program operating on the processor that creates child thread-local values 
for use by a child thread, wherein the child thread-local values are a function of the parent's 
thread-local values. 

33. A method for providing automatic inheritance of parent thread-local values to a 
child thread upon child thread creation, wherein a parent thread is associated with the parent's 
thread-local values, the method comprising: 

determining the parent's inheritable thread-local values; and 

automatically initializing the child's thread-local values corresponding to the parent's 
inheritable thread-local values, upon child creation, based on a predetermined child value 
method. 
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ABSTRACT 

In a threading mechanism, a system and method for providing automatic value 
inheritance when a pa-ent thread creates a child thread. Upon thread creation, the system 
iterates over all of the inheritable thread-local values associated with a parent thread and 
initiahzes a child's values of these inheritable thread-local values, based on an appropriate child 
value method. The child's values may be a copy of the parent's values, or a predetermined 
function of the parent's values. 
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variable A 
(type Object) 





value lA 









childValue method 
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Thread 1. 1 I value 
i i I.IA 
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value I Thread 2.1 
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Constructor Summary 



ThreadLocal () 
Creates a ThreadLocal variable. 



Method Summary 



Object 


get() ^ ■ 
Returns the value in the calling thread's copy of this ThreadLocal variable 


Protected 
Object 


InitialValue 0 

Returns the calling thread's initial value for this ThreadLocal variable 


void 


set fObiect value") 

Sets the calling thread's instance of this ThreadLocal variable to the given value 



Methods inherited from class java.lang.Object 

clone, eguals, finalize, getClass, hashCode, notify, notifyAll, notifvAll, toString. wait7 



Constructor Detail 



ThreadLocal 

public ThreadLocal 

Creates a ThreadLocal variable. 



Method Detail 



initialValue ~ 

protected Object initialValue ( ) 

Returns the calling thread's initial value for this ThreadLocal variable. This method will be 
called once per accessing thread for each ThreadLocal, the first time each thread accesses the 
variable with get or set. If the programmer desires ThreadLocal variables to be initialized to 
some value other than null, ThreadLocal must be subclassed, and this method overriden. 
Typically, an anonymous inner class will be used. Typical implementations of initial Value 
will call an appropriate constructor and return the newly constructed object. 

— - — 

public Object get ( ) 

Returns the value in the calling thread's copy of this ThreadLocal variable. Creates and 
initializes the copy if this is the first time the thread has called this method. 



public void set ( Object value) 

Sets the calling thread's instance of this ThreadLocal variable to the given value. This is only 
used to change the value from the one assigned by the initialValue method, and many 
applications will have no need for this functionality. 
Parameters 

value - the value to be stored in the calling threads' copy of this ThreadLocal. 



Constructor Summary 



InheritableThreadLocal ( 



Creates an Inheritable ThreadLocal variable. 



Method Summary 



protected 
Object 



childValue (Object parentValue') ~ ' ^ 

Computes the child's initial value for this Inheribatle ThreadLocal as a function 
of the parent' s value at the time the child Thread is created. 



Methods inherited from class java.Iang.ThreadLocal 



get, initialValue. sgt 



Methods inherited from class java.Iang.Object 

clone, eguals, fmalize, getClass, hashCode, notj;^, notifVAll, toString^j 



Constructor Detail 



InheritableThreadLocal 

public InheritableThreadLocal ( ) 

Creates an InheritableThreadLocal variable. 



Method Detail 



childValue ' ~~ ~ " 

protected Object childValue (Object parentValue) 

Computes the child's initial value for this Inheritable ThreadLocal as a function of the parent's 
value at the time the child Thread is created. This method is called from within the parent 
thread before the child is started. 



This method merely returns its input argument, and should be overridden if a different 
behavior is desired. 



Inheritable Hash Table 1 


TLRA 


value lA 


TLRB 


value IB 







TLR = Thread-Local Reference 



Non-Inheritable Hash Table 1 


TLRX 


value IX 
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Inheritable Hash Table 2 


TLRA 


value 2A 


TLRB 


value 2B 









Non-Inheritable Hash Table 2 




TLRX 


value 2X 


1 TLR = Thread-Local Reference | 
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DECLARATION AND POWER OF ATTORNEY 
FOR ORIGINAL U.S. PATENT APPLICATION 



Attorney's Docket No. SUNlP247 

As a below-named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name. 

I believe that I am the original, first and sole inventor (if only one name is listed below) or an original, first and joint inventor (if 
plural names are listed below) of the subject matter which is claimed and for which a patent is sought on the invention entitled- 
INHERITABLE THRRAn-T. OCAT. STORACtF. the specification of which, 

(check one) 1. ^ is attached hereto. ^ 

2. Q was filed on as 

U.S. AppHcation No. 

and was amended on . 



3. □ was filed on 

International PCT Application No. 
and was amended on 



I' |ereby state that I have reviewed and understand the contents of the above-identified specification, including the claims, as 
Mended by any amendment referred to above. 

f acknowledge the duty to disclose information which is material to the examination of this application in accordance with Title 
3^CFR§ 1.56. 

Mor Foreign Application(s) 

I=fereby claim foreign priority benefits under Title 35, United States code, § 119(a)-(d) or § 365(b) of any foreign application(s) 
foji patent or inventor's certificate, or § 365(a) of any PCT International application which designated at least one country other 
&in the United States, Hsted below and have identified below, by checking the box, any foreign application for patent or 
inventor's certificate, or PCT International application haviag a filing date before that of the application on which priority is 
claimed: 

Priority Benefits Claimed? 

Yes No 

(Application No.) (Country) (Filing Date) 

— Yes No 

(Application No.) (Country) (Filing Date) 

Provisional Application(s) 

I hereby claim the benefit under 35 U.S.C. § 1 19(e) of any United States provisional application(s) listed below: 



(Application No.) (Filing Date) 



(Application No.) (FiUng Date) 



Atty. Dkt. No.: SUN12P247/P4133 

(Revised 3/29/99) 
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Prior U.S, Applicatioii($) 

I hereby claim the benefit under Title 35, United States Code, § 120 of any United States application(s), or § 365(c) of any PCT 
International application designating the United States, listed below and, insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States or PCT Intemational appHcation in the manner provided by the first 
paragraph of Title 35, United States Code, § 112, I acknowledge the duty to disclose information which is material to 
patentability as defmed in Title 37, Code of Federal Regulations, § 1.56 which became available between the filing date of the 
prior application and the national or PCT intemational filing date of this application: 



(Application No.) (Filmg Date) (Status - patented, pending, abandoned) 



(Application No.) (Filmg Date) (Status - patented, pending, abandoned) 

Power of Attorney 



And I hereby appoint the law firm of Beyer & Weaver, LLP and all practitioners who are associated with the Customer Number 
022434 as my principal attomeys to prosecute this application and to transact all business in the Patent and Trademark Office 
connected therewith. 



Dfrect Correspondence To: 



Customer Number: 022434 

BEYER & WEAVER, LLP 



liilill 
022434 

pftTENT nmm office 



Direct Telephone Calls To: 



Attorney Name at telephone number (650) 493-2100 



I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and 
be|ief are believed to be true; and further that these statements were made with the knowledge that willful false statements and the 
Wge so made are punishable by fine or imprisonment, or both, imder section 1001 of Title 18 of the United States Code, and that 
such willful false statements may jeopardize the validity of the application or any patent issuing thereon. 



Tj^ewritten Full Name of 
Sole or First Inventor: _ 

Inventor's signature: 

Residence: (City) 
Post Office Address: 



Citizenship: US 

Date of Signature: 

(State/Country) CA/US 



1 199 Cordelia Avenue. Sa n Jose. CA 95 1 29 



Atty. Dkt. No.: SUN12P247/P4133 

(Revised 3/29/99) 
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